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CONTROLLING ACCESS TO A RESOURCE BY A PROGRAM USING A DIGITAL SIGNATURE 

The present invention relates to a computer system and particularly, but not exclusively, to 
a so-called secure computer system. 

In many computer systems, it is necessary to control access to certain resources, such as areas 
of computer memory, cryptographic keys or other sensitive data. This might be because they 
contain secret information, because the resource is scarce, because the resource has intrinsic 
value or a combination of factors. In such systems it may be necessary to allow some parties 
access to the resources while denying access to other parties. 

There are a number of existing systems which are designed to enforce access control to such 
resources. There are, however, other more demanding systems where simply controlling 
who can access the resource is not sufficient. In these systems it may also be necessary to 
control what is done with the resource. 

The present invention aims to provide an improved method for securing a resource on a 
computer system and an improved computer system. 

Accordingly, the present invention provides a method of controlling access to a resource in 
a computer system by a body of code having a signature associated therewith, the method 
comprising the steps of providing a cryptographic key associated with said resource, 
conducting a verification operation on said signature using the cryptographic key associated 
with said resource and controlling access to the resource by the code in dependence upon the 
result of said verification operation. 

The present invention also provides a computer system comprising verification means for 
verifying a digital signature associated with a body of program code and a resource having 
a cryptographic key associated therewith wherein said verification means is operable to use 
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said cryptographic key to verify said digital signature thereby to allow access of the code to 
said resource in dependence upon the verification. 

The invention provides a novel system for controlling, on a fine grained basis, what can be 
done with a resource. In our system the actions will be carried out by a computer program 
and our invention allows various resources to specify which parties may perform which 
actions. 



The present invention will now be described, by way of example only, with reference to the 
accompanying drawings in which: 

Figure 1 is a diagrammatic representation of a conventional secure computer system; 
Figure 2 is a representation of the operation of the system of Figure i; 
Figure 3 is a representation of a second known computer system; 

Figure 4 is a diagrammatic representation of a secure computer system according to the 
present invention; 

Figure 5 is a representation of the operation of the system of Figure 4 ; 

Figure 6 is a representation similar to that of Figure 5 of the operation of a modification to 
the system of Figure 5; 

Figure 7 is a representation similar to that of Figure 5 of the operation of a second 
modification to the system of Figure 5; 

Figure 8 is a representation similar to that of Figure 5 of the operation of a third modification 
to the system of Figure 5; and 
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Figure 9 is a representation similar to that of Figure 5 of the operation of a fourth 
modification to the system of Figure 5. 

In the drawings like parts are given like reference numbers. 

Figure 1 is a representation of a hardware computing system 10 which allows a user access 
5 to a sensitive or restricted resource. The system has a host computer 1 2 connected to a secure 
module 1 4 which may be a card in the computer 1 0 or a separate and remote unit. The secure 
module 1 4 contains the resource 1 00, an execution engine 200 and an access control unit 300. 
The system 1 0 may constitute, for example, a main frame or server PC of a business such as 
a bank which may be accessed internally or by way of an on-line access, e.g. by a customer. 
10 The execution engine 200 is code which is running in the secure module 14 and has access 
to the security sensitive resource 100 which typically may be bank account data stored in 
Random Access Memory (RAM). 

In use, when a third party attempts to gain access to the resource 100 via the host computer 
12 the latter applies a computer program code 22 to the execution engine 200 to gain access 

15 to the resource 1 00. The code 22 to be executed has a digital "signature" 24, in the form of 
a unique code, encoded either within the program code 22 or presented alongside the 
program code. The signature is indicated as Sig 1 to show that it is specific to a particular 
individual or group of individuals referred to here as the primary owner. Before the code is 
loaded into the execution engine 200 the signature is verified in the access control unit 300 

20 using a cryptographic key (Key 1) and only if the verification is positive is the code allowed 
to load into the execution engine to give the third party access to the resource 100. 

Figure 2 is a representation of the operation of the system software and shows the program 
code 22 and associated digital signature 24 in the host computer 12, and the resource 100, 
execution engine 200 and access control unit 300 in the secure module 14. The access 
25 control unit 300 includes an access control device 302 which controls access to the resource 
100. 
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In use, the program code 22 to be executed by the execution engine 200 is applied to the 
access control unit 300. As indicated above, the code 22 to be executed has a digital 
"signature" 24, in the form of a unique code, encoded either within the program or presented 
alongside the program. The access control unit 300 contains a cryptographic key 304 (Key 
5 1 ), which may be referred to as the primary key, and a signature verifier 306 in the form of 
a comparator operable to check the signature 24 associated with the code. The cryptographic 
key 304 is set by the manufacturer of the secure module 14. The signature verifier 306 
checks the signature 24 using the cryptographic key 304 in the access control unit 300. 
Providing the signature 24 on the code is correct, the access control unit 300 allows the code 
10 to be loaded into the execution engine 200 where it can be run and gain access to the 
resource. 

Thus, the verification of the signature relies upon key 304 that is built into the access control 
unit 300 by the module manufacturer and it is the loading of the code 22 into the execution 
engine 200 which is controlled by the verification process. 

15 Figure 3 shows a conventional variant of the system of Figure 2 where the primary owner 
wishes to delegate access to the resource 100 to another party. The code 22 contains a 
delegation certificate 101 consisting of a further cryptographic key 42 (Key 2) and the 
signature 24 of the primary owner, possibly accompanied by other data. The code also 
contains a new signature 26 (Sig 2) for the other party, referred to here as the secondary 

20 owner, to whom the primary owner of the first signature 24 wishes to delegate access to the 
resource. In this system the key 304 (Key 1) built into the access control unit 300 uses the 
verifier 306 to verify the signature 24 of the primary owner on the certificate 101 while a 
second verifier 308 checks the second signature 26 of the secondary owner on the code 
against the key 42 of the primary owner in the certificate 101. The outputs of the two 

25 verifiers are taken together using an "and" operation 3 1 0 and only if the first signature AND 
the second signature are verified is the secondary owner allowed access to the resource 100 
by the access control device 300. 
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A common property of these conventional systems is that ultimately the verification of the 
signature, or the chain of delegation certificates, ends with a key that is built into the system. 
It is up to the owner of the system which keys are to be trusted for which operations. 

Figure 4 is a representation similar to that of Figure 1 of a preferred form of hardware 
5 computer system 50 according to the invention. In Figure 4, the secure module 1 4 contains 
a secure sub unit 30 in which the execution engine 200 is located. The access control unit 
300 and the resource 1 00 are separated from the execution engine 200 within the module 1 4 
so that the execution engine 200 operates within the secure sub-unit 30. The separation of 
these devices may be physical, by means of controlling the electrical and mechanical 

1 0 connections between the devices, or through logical separation in the operation of software 
components within the computer system. The resource 1 00 also contains a cryptographic key 
1 02 (Key 1 ) which is the primary key and is similar to key 304 of Figures 2 and 3. However, 
the key 102 is set by the owner of the resource 100 and not by the manufacturer of the 
module 14. It will be appreciated that, as mentioned above, although 14 is referred to as a 

1 5 module it may be in the form of a card contained within the host computer 1 2 or may be one 
or more discrete units physically separate from the host computer 12. 

The host computer 12 may communicate with the execution engine 200 only through the 
access control unit. As shown in Figure 4, any code operating within the secure sub-unit 30 
is unable to access any resource outside the secure sub-unit 30 other than by issuing a request 
20 through the access control unit 300. 

When the host system 1 0 attempts to load the program code 22, togther with its associated 
authentication signature 24, into the execution engine 200, this code is first passed through 
the access control unit 300 which checks that the signature 24 associated with the code 22 
is a valid signature using the key 102. At this point, the access control unit 300 does not 
25 associate this signature with any authority to access the resource 1 00. However, the access 
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control unit 300 records the identity of the signature creator and associates this with the 
program code 22 that has been loaded. When the program code 22 is subsequently executed 
by the execution engine 200 within the sub-unit 30, the code may request access to the 
resource 100 and the request is passed through the access control unit 300. The identity 
5 recorded against the code at the time that it was loaded is then checked by the access control 
unit 300 using an access control policy to ascertain what actions, if any, are authorised by the 
signature 24. Only those authorised actions are allowed to be carried out on the resource 1 00. 

Figure 5 is similar to Figure 2 and is a representation of the operation of the system software 
within the module 14. 

10 In the system of Figure 5, the resource has associated with it the cryptographic key 102 
which may be used to verify the digital signature 24 associated with the body of program 
code 22. The program code, along with its associated digital signature 24 is first loaded into 
the module 14 where the access control block 300 compares the signature with the key 102 
associated with the resource 1 00. The access control unit 300 includes access control device 

1 5 302 which controls access to the resource 1 00, and signature verifier 306. If the signature is 
correctly verified then the code is allowed to load in the execution engine 200 but still does 
not have access to the resource 1 00 and the access control unit 300 records the identity of the 
signature creator and associates this with the program code 22 that has been loaded. 

If the user then requires access to the resource 100 to carry out a particular operation, the 
20 code 22 is run in the execution engine 200 and requests access to the resource 100. This 
access has to be effected through the access control unit 300 and at this stage the signature 
24 is checked against the access control policy. 

In its simplest form in Figure 5 the signature 24 is verified against the key 1 02 by the verifier 
306 and if verified access is allowed to the resource 100. Thus, it is the resource itself that 
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determines which code is allowed access to the resource because the key 102 is in the 
resource and not the module 100. This means that each user can set his own key in his own 
data block in the resource 100 and this is not therefore accessible by whoever has access to 
the module 14. 
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In variants of this invention more than one signature can be applied to the program code 
using different cryptographic keys. In this case access to the resource will be granted if any 
of the signatures verify against any of the listed keys given with the resource. The signature 
on the program code may be replaced by a signature on a cryptographic hash of the program 
code, a signature on a set of hashes of parts of the program code, on a hash or hashes of the 
parts of the program code or on any other method which allows the verification of the 
signature to be completed only if the code is identical to the code upon which the signature 
was originally placed, since the signature is unique to the code. 



The keys associated with the resource may be replaced by cryptographic hashes of those keys 
or other identifiers of the keys which allow the device uniquely to identify the correct keys 
15 with which to verify the signature. In these cases the real signature verification keys must 
be available to the device in order to carry out the verification process. 



In this invention the signature can be any form of digital or electronic signature which can 
be verified by the device. 



The system of Figure 5 does not restrict the actions which the signature holder might carry 
20 out on the resource 1 00 once the code is allowed access to the resource 1 00 by the access 
control unit 300, since the key does not have any access restrictions associated with it. 
Figure 6 shows a system in which the actions are restricted to those allowed by the associated 
key. In this system, the resource 1 00 has associated with it an access control list (ACL) 1 06 
comprisingkey sets 108. Each set 108 indicates some actions which may be performed using 
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the resource, some key which may be used to authorise those actions and, optionally, some 
constraints upon those actions including time limits, usage limits, parameter limits or other 
constraints. As before, the resource is made available to the execution engine 200 but this 
time it is bound to the access control lists rather than simply to keys. The program code 22 
is loaded into the execution engine 200 as before along with the signature 24 upon the code. 
The code may then be executed inside the execution engine 200 and when the code attempts 
to carry out any operation upon the resource the access control list 106 is checked. If the 
signature on the code can be verified by the verification unit 306 with respect to one of the 
keys in the ACL the access control unit 300 allows the code access to the operations listed 
in the ACL entry which has the correct key, providing the access falls within any given 
constraints. Otherwise the actions are not permitted. For example, one access key may allow 
the user read only rights to data in the resource whilst another might allow read/write access. 
Another possibility where the resource is memory is for different keys to allow access to 
different parts of memory. 

In a third version of the invention (Figure 7) intermediate access control lists may be used 
to delegate control. The code 22 contains a delegation certificate 400 consisting of a further 
cryptographic key 402 (Key 3) and the signature 24 of the primary owner. The code also 
contains a new signature 28 (Sig 2) for the secondary owner, to whom the primary owner of 
the first signature 24 wishes to delegate access to the resource 1 00. As in the embodiment of 
Figure 6 the use of the resource 1 00, or individual operations on the resource, is associated 
with signature verification keys 108 of access control list 106. However, in this system 
delegation credentials may be constructed in the following manner: an access control list 402 
in the delegation certificate 400 is built in a similar form to the list 106 associated with the 
resources. This list 402 is then signed using the cryptographic signature key 24. The 
resource 1 00 is made available to the execution engine 200, along with its access control list 
106, and the program code 22, its signature 28, and the delegation credential 400, including 
its signature 24 are all loaded into the execution engine 200. The signatures on the code can 
be checked by verification unit 308 against the keys in delegation credential 400 and the 
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signature 24 on the delegation credential is verified against the keys 108 in the resource's 
access control list 106 using verification unit 306. The intersection is taken at 310 of the 
operations listed in validated ACL entries and validated delegation credentials. Access is 
granted by access control device 302 to the code for operations that fall within this 
intersection of operations. 

It will be appreciated, therefore, that one user with rights to one part of the resource 100 can 
sign off or delegate part or all of those rights to a third party. Referring again to Figure 7, 
the output of verifier 308 shows operations identified as [2, 3, 4] being allowed by the 
verification check of the secondary owner's signature 28 against the delegation key 402, for 
that signature, of the code access control list 400. However, the output of verifier 306 shows 
only operations identified as [1, 3] being allowed by the verification check of the primary 
owner's signature 24 against the delegation key 108 in the resource access control list 106 
for that signature. Thus, the secondary owner is only allowed to carry out operation [3] on 
the resource 100. 

In a fourth variant of this invention (Figure 8) access can be granted to all code which is 
authorised under the system shown in Figure 6 as well as code authorised as described above 
in relation to Figure 7. Multiple levels of delegation may be permitted in which the operation 
must be listed in each ACL with a key which verifies the signature on the next credential, or 
which verifies the program code in the last credential. 

As shown in Figure 8 this scheme can be used to allow multiple bodies of code 22a, 22b to 
have differing levels of access to the same resource 100 by having different delegation 
certificates 400a, 400b and signatures 24a, 24b, 28, 32. 

The codes 22a, 22b are loaded into different execution engines 200a, 200b within the secure 
module 14. It will be appreciated that the different execution engines 200a, 200b, as well as 
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individual resources, may be in different secure sub units within the secure module 14 and 
cannot therefore interfere with one another. 



In a further modification (Figure 9) the system of Figure 8 can be used to allow one body of 
code 22 different levels of access to more than one resource 100a, 100b. 

The code 22 is similar to code 22a or 22b of Figure 8 but has two or more delegation 
certificates 400a, 400b, each with a cryptographic key 402a, 402b and signature 24, 26. Here 
there are two primary owners of signatures 24, 26 who both wish to delegate to the same user 
or secondary owner of signature 28. The secondary user is granted different rights to the two 
resources 1 00a, 1 00b in dependence on the delegation credentials. The access control unit 
of Figure 9 can perform the verification for both primary signatures 24, 26 and the secondary 
signature 28 at the same time as is indicated by the broken lines. In the example of Figure 
9, the secondary user is allowed by the ACLs of the delegation certificate 400a of primary 
owner of signature 1 to carry out operation [3] where the resource 100a, 100b allows 
according to its own ACL whilst the secondary user is allowed by the ACLs of the delegation 
certificate 400b of primary owner of signature 2 to carry out operations [2, 3] where the 
resource 100a, 100b allows. 



In a further modification of the system, which may be combined with previous versions, the 
access control lists either attached to the resources or used in the delegation certificates can 
specify that any further delegation certificate must contain a "challenge" value. In this 
system when accessed by the code the access control unit 300 returns a "challenge" value 
which is unlikely to be guessed usually because the number is large and appears to be 
random. The access control unit 300 keeps a record of all the challenges that have been 
issued, along with information about the how long the challenge value is considered to be 
valid. For the code to be allowed access to operations permitted by an ACL entry requiring 
a challenge it must have a certificate that includes a currently valid challenge and this must 
be correctly signed. By controlbng the lifetime of the challenge the system can control the 
lifetime of certificates used by the code. This can be used to grant temporary access rights 
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to a body of code. 

The differences between known systems and the system of the present invention will clearly 
be understood from the foregoing. In particular, in known systems, the code once authorised 
can access any available resource and the system requires the secure unit to protect the code, 
5 the resources and the checking process from hostile external attacks. In contrast, in the 
system of the present invention, the authorisation is contained in the resource access rather 
than the loading of the code and the secure sub-unit 1 80 not only protects the code, resources 
and the checking process from hostile external attacks but also protects the resources and 
checking processes from attacks from hostile code already loaded in the execution engine 
1 0 200. This extra protection is necessary owing to the delayed nature of the authorisation of 
accesses to the resources. 



It will be appreciated that the code, once loaded in the secure sub-unit 180, can perform any 
operation within the sub-unit including altering the code itself, since the authenticity of the 
code is checked before execution begins. It will also be appreciated that the present 
1 5 invention is more efficient than systems where the code is authenticated each time an access 
to the resources is made since the signature on the code need only be validated once. 

In cases where more than one signature is applied to the code before it is loaded, all of the 
signatures are verified as the code is loaded and the identities of all the code signors are 
recorded. When an access to a resource is made, either the verification device can allow the 
20 access if any of the signors would have the right to make the access or, alternatively, the code 
might indicate in the request the identity whose credentials should be used for the 
authorisation. 



In all of the systems represented in the drawings, various resources are required to be 
accessed by particular blocks of computer program code. The programs may be general 
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purpose programs which make use of the various resources. An aim of the invention is to 
control the access to the resources so that only authorised programs may access the resources 
in authorised ways or cryptographic keys which may be accessed by selected users. 



It is up to the owner of the computer system to determine which keys are to be trusted for 
5 which operations. Consequently, if further resources are added to the computer system, 
further keys must be added to the access control unit 300. 



12 



WO 01/63385 



PCT/GB01/00688 



CLAIMS: 

1 A method of controlling access to a resource (100) in a computer system by a body 
of code (22) having a signature (24) associated therewith, the method comprising the steps 
of: 

(i) providing a cryptographic key (102) associated with said resource; 

(ii) conducting a verification operation on said signature (24) using the cryptographic 
key (102) associated with said resource (100); 

(iii) and controlling access to the resource (100) by the code (22) in dependence upon 
the result of said verification operation. 

2 A method as claimed in claim 1 wherein: 

said code (22) has a plurality of signatures (24, 28) associated therewith; 

step (ii) comprises conducting a verification operation on each said signature (24, 28) 
using said cryptographic key (102) associated with said resource (100); 

and step (iii) comprises allowing said code access to said resource in response to any 
one of said signatures being verified. 

3 A method as claimed in claim 1 wherein: 

said code (22) has a plurality of signatures (24, 28) associated therewith; 

step (ii) comprises conducting a verification operation on each said signature (24, 28) 
using said cryptographic key (102) associated with said resource (100); 

and step (iii) comprises allowing said code access to said resource only in response 
to all of said signatures being verified. 

4 A method as claimed in any of claims 1 to 3 further comprising: 
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providing an execution engine (200) separate from said resource (100) for executing 
said code (22); 

and step (iii) comprises loading said code into said execution engine in response to 
said signature being verified. 

5 A method as claimed in any of claims 2 to 4 wherein: 

said resource (100) has a plurality of associated keys (102); 

step (ii) comprises conducting a verification operation on each said signature (24, 28) 
using each said cryptographic key (102) associated with said resource (100); 

and step (iii) comprises allowing said code access to said resource in response to any 
one of said signatures being verified. 

6 A method as claimed in any of claims 2 to 4 wherein: 
said resource (100) has a plurality of associated keys (1 02); 

step (ii) comprises conducting a verification operation on each said signature (24, 28) 
using each said cryptographic key (102) associated with said resource (100); 

and step (iii) comprises allowing said code access to said resource only in response 
to all of said signatures being verified. 

7 A method as claimed in claim 4 fiirther comprising: 

(iv) conducting a further verification operation on said signature (24) using the 
cryptographic key (102) associated with said resource (100) in response to said code (22) in 
said execution engine (200) attempting to access said resource; 

(v) and further controlling access to the resource (100) by the code (22) in 
dependence upon the result of said verification operation. 



14 



WO 01/63385 



PCT/GB01/00688 



8 A method as claimed in claim 7 wherein: 

said code (22) has a plurality of signatures (24, 28) associated therewith; 

step (i v) comprises conducting a verification operation on each said signature (24, 28) 
using said cryptographic key (102) associated with said resource (100); 

and step (v) comprises allowing said code access to said resource in response to any 
one of said signatures being verified. 

9 A method as claimed in claim 7 wherein: 

said code (22) has a plurality of signatures (24, 28) associated therewith; 

step (i v) comprises conducting a verification operation on each said signature (24, 28) 
using said cryptographic key (102) associated with said resource (100); 

and step (v) comprises allowing said code access to said resource only in response 
to all of said signatures being verified. 

10 A method as claimed in any of claims 7 to 9 wherein: 

said resource (100) has a plurality of associated keys (102); 

step (iv) comprises conducting a verification operation on each said signature (24, 28) 
using each said cryptographic key (102) associated with said resource (100); 

and step (v) comprises allowing said code access to said resource in response to any 
one of said signatures being verified. 

1 1 A method as claimed in any of claims 7 to 9 wherein: 

said resource (100) has a plurality of associated keys (102); 

step (iv) comprises conducting a verification operation on each said signature (24, 28) 
using each said cryptographic key (102) associated with said resource (100); 

and step (v) comprises allowing said code access to said resource only in response 
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to all of said signatures being verified. 

12 A method as claimed in any of claims wherein the or each said key (102) is 
configured to authorise preselected actions on said resource (100). 

13 A method as claimed in any of claims 1 to 1 1 wherein: 

the or each said key (102) is configured to authorise preselected actions on said 
resource (100); 

and following verification of the or one of the signatures by a said key associated with 
said resource, access to said resource by said code (22) is allowed only in relation to those 
preselected actions associated with said key. 

14 A method as claimed in any of claims 1 to 13 comprising: 

providing said code (22) with first and second signatures (24, 28); 

associating a cryptographic key (402) for said second signature with said first 
signature; 

step (ii) comprises conducting a verification operation on said first signature (24) 
using said cryptographic key (108) associated with said resource (100), and conducting a 
verification operation on said second signature (28) using said cryptographic key (402) 
associated with said first signature (24); 

and step (iii) comprises allowing said code access to said resource in response to both 
of said signatures being verified. 

1 5 A method as claimed in claim 14 wherein: 

one of said keys (24, 108) is configured to authorise preselected actions on said 
resource (100); 
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and following verification of said signatures by said keys, access to said resource by 
said code (22) is allowed only in relation to those preselected actions associated with said one 
of said keys. 

16 A method as claimed in claim 14 wherein: 

each of said keys (24, 108) is configured to authorise preselected actions on said 
resource (100); 

and following verification of said signatures by said keys, access to said resource by 
said code (22) is allowed only in relation to those preselected actions which are common to 
said keys. 

1 7 A computer system comprising: 

verification means (300) for verifying a digital signature associated with a body of 
program code (22); 

and a resource having a cryptographic key associated therewith; 

wherein said verification means is operable to use said cryptographic key to verify 
said digital signature thereby to allow access of the code to said resource in dependence upon 
the verification. 

1 8 A system as claimed in claim 1 7 further comprising an execution engine means for 
running said program code; 

wherein said execution engine means is separate from and is coupled to said resource 
by way of said verification means (300); 

and said verification means is operable to verify said code both prior to said code 
loading into said execution engine means and prior to said code accessing said resource from 
said execution engine means. 
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1 9 A system as claimed in claim 1 8 wherein said verification means, said resource and 
said execution engine means are contained within a secure module. 
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